GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Fundamental Modeling Concepts</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Fundamental Modeling Concepts</span></h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr"><p><b>Fundamental Modeling Concepts</b> (<b>FMC</b>) sind eine semi-formale <a href="Methodik" title="Methodik">Methodik</a> zur <a href="Kommunikation" title="Kommunikation">Kommunikation</a> über komplexe <a href="Software" title="Software">Software</a><a href="System" title="System">systeme</a>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Geschichte">Geschichte</h2></div>

<p>Seit Ende der 1970er Jahre wurden ihre Grundlagen von <a href="Siegfried_Wendt_(Informatiker)" title="Siegfried Wendt (Informatiker)">Siegfried Wendt</a> und seinen Mitarbeitern und Schülern an der <a href="Technische_Universit%C3%A4t_Kaiserslautern" title="Technische Universität Kaiserslautern">Universität Kaiserslautern</a> entwickelt. An dem 1999 unter Leitung von Siegfried Wendt gegründeten <a href="Hasso-Plattner-Institut" title="Hasso-Plattner-Institut">Hasso-Plattner-Institut</a> an der <a href="Universit%C3%A4t_Potsdam" title="Universität Potsdam">Universität Potsdam</a> wurden diese Konzepte zunächst unter dem Namen SPIKES (<b>S</b>tructured <b>P</b>lans for <b>I</b>mproving <b>K</b>nowledge Transfer in <b>E</b>ngineering of <b>S</b>ystems) gelehrt, bevor sie im Jahr 2001 den Namen FMC (<b>F</b>undamental <b>M</b>odeling <b>C</b>oncepts) erhielten.

</p>

<div class="mw-heading mw-heading2"><h2 id="Relevanz">Relevanz</h2></div>

<p>Mit FMC werden eine Vielzahl von Softwaresystemen analysiert, entworfen und dokumentiert. Bekannter Nutzer ist u. a. das Walldorfer Softwarehaus <a href="SAP" title="SAP">SAP</a>, welches die <a href="SAP_R/3" class="mw-redirect" title="SAP R/3">SAP R/3</a> Architektur damit dokumentiert. <a href="Hasso_Plattner" title="Hasso Plattner">Hasso Plattners</a> Begeisterung für diese Methodik resultierte in der Gründung des HPI (<a href="Hasso-Plattner-Institut" title="Hasso-Plattner-Institut">Hasso-Plattner-Institutes</a>), welches die Lehren von FMC in der Vergangenheit in der universitären Grundausbildung vermittelte.

</p>

<div class="mw-heading mw-heading2"><h2 id="Einführung"><span id="Einf.C3.BChrung"></span>Einführung</h2></div>

<p>Nach FMC gibt es drei miteinander verwobene Arten, Softwaresysteme zu betrachten:

</p>

<ul><li>Aufbau des Systems</li>

<li>Abläufe im System</li>

<li>Wertebereiche</li></ul>

<p>Für jede dieser Betrachtungsweisen gibt es einen Diagrammtyp, mit dessen Hilfe der jeweilige Aspekt zeichnerisch dargestellt werden kann. Die resultierenden, meist leicht zu erstellenden, aber auch leicht zu verstehenden <a href="Diagramm" title="Diagramm">Diagramme</a> haben FMC unter seinen Anhängern populär gemacht.

</p><p>Grundsätzlich dienen FMC-Diagramme einem von zwei Zwecken: Sie sollen entweder von einer Gruppe verwendet werden, um über ein Softwaresystem zu kommunizieren, oder sie werden benutzt, um andere (Entwickler, Kunden, Manager etc.) in ein Softwaresystem einzuführen. Im ersten Falle werden die Diagramme meist etwas umfangreicher, um die Kommunikation über komplexere Zusammenhänge zu erleichtern; im zweiten Fall werden aus didaktischen Gründen zumeist kleine Diagramme mit wenigen Komponenten verwendet. Immer aber sollen Ästhetik und Anschaulichkeit im Vordergrund stehen, da wesentlicher Antrieb in der Verwendung von FMC die Förderung der Kommunikation sein soll. Deshalb sind die Diagramme zwar wichtigster Bestandteil von FMC, erübrigen aber keinen Kommentar.

</p>

<div class="mw-heading mw-heading2"><h2 id="Diagramme">Diagramme</h2></div>

<p>Allen Diagrammen ist gemein, dass es sich um sogenannte <a href="Bipartiter_Graph" title="Bipartiter Graph">bipartite Graphen</a> handelt. Ein bipartiter Graph ist dabei ein <a href="Graph_(Graphentheorie)" title="Graph (Graphentheorie)">Graph</a>, dessen <a href="Knoten_(Graphentheorie)" title="Knoten (Graphentheorie)">Knoten</a> aus zwei verschiedenen <a href="Klasse_(Mengenlehre)" title="Klasse (Mengenlehre)">Klassen</a> stammen, mit der Bedingung, dass kein Knoten direkt mit Knoten aus seiner Klasse verbunden sein darf. Die Knoten der einen Klasse werden immer als <a href="Rechteck" title="Rechteck">Rechteck</a> gezeichnet (eckiger Knoten), die Knoten der anderen als <a href="Kreis" title="Kreis">Kreis</a>, <a href="Ellipse" title="Ellipse">Ellipse</a>, <a href="Oval" title="Oval">Oval</a> oder Stadion (Rechteck mit zwei angesetzten Halbkreisen an zwei gegenüberliegenden Seiten) gezeichnet (runder Knoten).

</p><p>Außerdem können in allen Diagrammen dargestellte Zusammenhänge nahezu beliebig in anderen Diagrammen gleichen Typs verfeinert oder <a href="Abstraktion" title="Abstraktion">abstrahiert</a> werden. Damit können alle für die Software relevanten Abstraktionsstufen eines Systems mit der gleichen Methodik dargestellt werden.

</p>

<div class="mw-heading mw-heading3"><h3 id="Aufbaudiagramme">Aufbaudiagramme</h3></div>

<p>Ein Aufbaudiagramm beschreibt, wie eine Menge von Systemkomponenten zueinander in Beziehung stehen. Zu diesem Zwecke wird jede Komponente als <i>Akteur</i>, <i>Kanal</i> oder <i>Speicher</i> identifiziert. Kanäle und Speicher werden auch als passive Komponenten bezeichnet, Akteure entsprechend als aktive Komponenten. Dabei können passive Komponenten nicht direkt mit anderen passiven Komponenten in Beziehung stehen, ebenso wenig wie aktive mit aktiven. Daraus resultiert ein bipartites Systemverständnis, das seinen Niederschlag in bipartiten Aufbaubildern findet.

</p>

<div class="mw-heading mw-heading4"><h4 id="Struktur">Struktur</h4></div>

<p>In Aufbaubildern werden aktive Komponenten durch eckige Knoten und passive Komponenten durch runde Knoten dargestellt, wobei Kanäle meist durch einen kleineren Kreis, und Speicher durch ein größeres Oval oder Stadion dargestellt werden. Die <i>Kanten</i> (Verbindungslinien) zwischen Speichern und Akteuren müssen <i>gerichtet</i> sein, zwischen Kanälen und Akteuren können sie auch <i>ungerichtet</i> sein. Die Richtung hat folgende Bedeutung:

</p>

<ul><li>Speicher/Kanal → Akteur: Akteur liest aus Speicher bzw. empfängt vom Kanal</li>

<li>Akteur → Speicher/Kanal: Akteur schreibt in Speicher bzw. sendet über Kanal</li></ul>

<p>Es gibt keine Kanten, die in beide Richtungen gerichtet sind. Stattdessen werden, um auszudrücken, dass ein Akteur sowohl aus einem Speicher liest als auch in diesen schreibt, zwei entgegengesetzt gerichtete Kanten verwendet (auch als <i>modifizierender Zugriff</i> bezeichnet). Bei Kanälen wird im Gegensatz dazu eine ungerichtete Kante benutzt.

</p><p>Knoten können gruppiert werden, um Gemeinsamkeiten zu veranschaulichen. Dazu wird einfach ein weiterer Knoten eingeführt, der diese anderen Knoten enthält. So können einige Akteure und Speicher Teil eines größeren Akteurs sein, dessen innerer Aufbau dargestellt werden soll, oder es gibt eine Menge von Speichern, auf die vom selben Akteur zugegriffen werden soll.

</p><p>Eine spezielle Form des Kanals ist ein Request/Response-Kanal, bei dem eine benutzende Komponente einen Dienst einer anderen Komponente aufruft und eine entsprechende Antwort erhält. Diese Kanäle werden mit einem „R“ und einem Pfeil gekennzeichnet, der von der aufrufenden zur aufgerufenen Komponente zeigt.

</p>

<div class="mw-heading mw-heading4"><h4 id="Strukturvarianz">Strukturvarianz</h4></div>

<p>Die Struktur vieler Softwaresysteme kann sich zur Laufzeit ändern. Diese Strukturvarianz wird in FMC folgendermaßen interpretiert: Das betroffene Teilsystem wird unabhängig von seiner tatsächlichen Struktur als Speicher aufgefasst, das von einem nicht in diesem Teilsystem enthaltenen Akteur modifiziert werden kann. Entsprechend werden im Aufbaubild ein Speicher (zur Unterscheidung mit gestrichelter Außenlinie), der dieses Teilsystem enthält, und der modifizierende Zugriff des Strukturvarianz-Akteurs auf diesen Speicher eingezeichnet.

</p>

<div class="mw-heading mw-heading3"><h3 id="Ablaufbilder">Ablaufbilder</h3></div>

<p>Abläufe werden mit einer Klasse von <a href="Petri-Netz" title="Petri-Netz">Petri-Netzen</a>, den Bedingungs-Ereignis-Netzen, dargestellt, da diese ebenfalls bipartit sind. In FMC-Petrinetzen kann jede Stelle normalerweise nur eine Marke aufnehmen, so dass die Schaltregel lautet:

</p><p><i>Eine Transition schaltet genau dann, wenn alle Eingangsmarken belegt sind und alle Ausgangsmarken, die nicht gleichzeitig Eingangsmarken sind, frei sind.</i>

</p><p>Zusätzlich gibt es noch Stellen, die beliebig viele Stellen aufnehmen können und durch einen Doppelkreis dargestellt werden. Besondere ,unendliche‘ Stellen sind <a href="Stapelspeicher" title="Stapelspeicher">Stack</a>-Stellen und Rücksprungstellen.

</p><p>Außerdem gibt es in FMC-Petrinetzen das Mittel der Auflösung von Konflikten über Bedingungsevaluierung. Gehen von einer Stelle mehrere Kanten ab, so können Bedingungen an diese Kanten geschrieben werden, anhand derer bestimmt werden kann, in welchem Fall welche Transition schaltet.

</p>

<div class="mw-heading mw-heading3"><h3 id="Wertebereichsbilder">Wertebereichsbilder</h3></div>

<p>Hierbei handelt es sich um leicht veränderte und erweiterte <a href="Entity-Relationship-Modell#ER-Diagramme" title="Entity-Relationship-Modell">Entity-Relationship-Diagramme</a>. <a href="Entit%C3%A4t" title="Entität">Entitäten</a> (Gegenstände) sind in FMC-Diagrammen runde Knoten, <a href="Relation_(Philosophie)" title="Relation (Philosophie)">Relationen</a> eckige. Entitäten können mit <a href="Entity-Relationship-Modell#Begriffe" title="Entity-Relationship-Modell">Attributen</a> behaftet werden, die als Liste im Knoten der Entität notiert werden. Abstraktion ermöglicht es Entitäten, Relationen zu enthalten, so dass Relationen in Relation zu anderen Entitäten oder Relationen stehen können. Partitionen von Entitäten werden entweder dargestellt, indem die Sub-Entitäten in die zu partionierende Entität gezeichnet werden, oder durch das dreieckige Partitionssymbol (das sozusagen die „Partitionsrelation“ darstellt).

</p>

<div class="mw-heading mw-heading3"><h3 id="Schichtendiagramme">Schichtendiagramme</h3></div>

<p>Zur exemplarischen Darstellung von quadratischen Relationen, d. h. Relationen auf <i>einer</i> Menge von Elementen, können sogenannte Schichtungsdiagramme genutzt werden. Dabei handelt es sich um die verkürzte Darstellung einer Matrixdarstellung, mit der sich beliebige zweistellige Relationen darstellen lassen. Beispielsweise kann dieser Diagrammtyp dazu genutzt werden, die Aufrufschichtung von Prozeduren oder die Abhängigkeiten der Pakete innerhalb eines Computerprogrammes darzustellen (wobei der Rekursionsfall ebenfalls darstellbar ist).

</p><p>Obwohl diese Form der Darstellung in einer Reihe FMC-basierter Modellierungsdokumente verwendet wird, ist sie nicht als konzeptioneller <i>Bestandteil</i> von FMC angesehen. Vielmehr handelt es sich um die fallweise nützliche Ergänzung der Beschreibung, so wie für bestimmte andere Aspekte UML-Klassendiagramme oder Bildschirmfotos zweckmäßige Beschreibungsmittel sind.

</p>

<div class="mw-heading mw-heading2"><h2 id="Siehe_auch">Siehe auch</h2></div>

<ul><li><a href="Unified_Modeling_Language" title="Unified Modeling Language">Unified Modeling Language</a>, eine graphische Modellierungssprache zur Spezifikation, Konstruktion und Dokumentation von Software-Teilen und anderen Systemen</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Literatur">Literatur</h2></div>

<ul><li>Siegfried Wendt: <i>Nichtphysikalische Grundlagen der Informationstechnik. Interpretierte Formalismen.</i> 2. Auflage. Springer-Verlag, Berlin Heidelberg 1991, ISBN 3-540-54452-6 (<a rel="nofollow" class="external text" href="https://www.fmc-modeling.org/download/publications/wendt_1991-nichtphysikalischeGrundlagenInformationstechnik.pdf">PDF; 7,31MB</a>).</li></ul>

<dl><dd>Eine PDF-Fassung, die durch den Autor nach Einstellung der ursprünglichen Verlagsauflage freigegeben wurde. Auch wenn dieses Werk nicht speziell auf die Beschreibung von FMC abzielt, sondern in Inhalt und Struktur sehr viel grundsätzlicher angelegt ist, so wird der interessierte Leser hier dennoch das FMC zugrundeliegende Erkenntnisfundament erkennen.</dd></dl>

<ul><li>Andreas Knöpfel, Bernhard Gröne, Peter Tabeling: <i>Fundamental Modeling Concepts: Effective Communication of IT Systems</i>, Wiley 2006, ISBN 0-470-02710-X</li></ul>

<ul><li>Peter Tabeling: <i>Softwaresysteme und ihre Modellierung</i>, Springer-Verlag Berlin Heidelberg 2005, ISBN 3-540-25828-0</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<ul><li><a rel="nofollow" class="external text" href="http://www.fmc-modeling.org/">FMC Hauptseite</a></li>

<li><a rel="nofollow" class="external text" href="https://www.fmc-modeling.org/page.php?category=fmc_stencils">FMC Stencils für Visio</a></li>

<li><a rel="nofollow" class="external text" href="https://www.arcway-cockpit.com/downloads/">Kostenfreie Werkzeuge für FMC-Aufbaudiagramme</a></li>

<li><a rel="nofollow" class="external text" href="https://www.bungerts.de/wordpress/wp-content/uploads/Nutzen-und-Herausforderung-bei-FMC.pdf">Whitepaper: Nutzen und Herausforderung bei der Modellierung mit den Fundamental Modeling Concepts</a></li></ul></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2026-01-11" href="https://de.wikipedia.org/wiki/?title=Fundamental_Modeling_Concepts&oldid=263233354">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>